1. Field of the Invention
The present invention pertains to computer programming, and, more particularly, to a visual programming tool for a computing apparatus.
2. Description of the Related Art
Despite dramatic increases in recent years, some impediments to the use of computing technology by society at large still persist. Historically, the greatest impediment, aside from the computing capabilities themselves, was the user interface with the computer, or platform. At one time, the user interface consisted of a prompt at which a user entered a command. Typically, the command had to be selected from a list of commands whose content depended on the operating system under which the platform ran. Most operating systems provided some flexibility to the user by permitting the use of parameters, sometimes called “switches,” in conjunction with the command. The user could then “program” the computer through the user interface to tailor the operation of the platform to their particular needs by entering the command and the appropriate parameters. The user could also open a text editor to create a text file that could be saved and used as a program.
This type of interface has some inherent drawbacks for programming. One significant drawback is that the commands and parameters must be memorized and/or looked up in a manual. This drawback is compounded by at least several factors. First, the commands and their parameters frequently were not intuitive, making them difficult to memorize. Second, the syntax for each command was typically very different. Third, the list of commands and parameters and the syntax frequently varied drastically depending on the type of operating system on which the platform was operating. These kinds of factors meant that the skills needed for interfacing with the computer were relatively specialized, and required some degree of time and effort to acquire. Consequently, the ability to work with computers remained limited to relatively small groups of people.
Much of this changed dramatically with the introduction of the “graphical user interface,” or “GUI.” The GUI takes the programming burden off the user by encapsulating the commands and their parameters in applications represented by graphical elements known as “icons” displayed to the user. The user then typically uses a pointing device, such as a mouse, a joystick, or a touchpad, to place a cursor over the icon. The choice is entered in manner depending on the type of pointing device employed. With a mouse, for instance, the user clicks a button, usually twice, to enter the selection. Thus, the user no longer needs to memorize lists of arcane commands and parameters, much less their syntax. Plus, the “drag and click” technique easily transfers to other platforms employing different GUIs. The user need only learn the functionality associated with the applications being selected.
The introduction of the GUI, coupled with dramatic increases in computing capabilities, opened the computing world to very many more users on a personal level. However, in taking the programming burden off the user, the encapsulation described above also inhibits the user's ability to program when they wish to do so. The GUI just does not include access to the programming levels of the operating system. The user can exit the GUI to enter a text-based interface such as the one first described. At that point, programming can occur. Or, the user can open a text editor with the GUI and enter text that will constitute a program. However, the user must still have previously acquired a working knowledge of the programming language, including commands, parameters, and syntax. But the GUI itself offers no way to visually program the platform without knowledge of a programming language's commands, parameters, and syntax.
Some attempts have been made to remedy this situation. For instance, an application known as “Khoros Cantata” uses graphical elements known as “glyphs” on a grid to replace lines of code to perform a kind of “visual programming.” However, this technique only alleviates the need to manually enter the text of the program. The user is still required to program, and manual entry of values is still generally required. There is also a type of scripting where a user interface (“UI”) is generated based on some criteria and then presented to the user at either design or runtime (e.g., Commando, Linux GUI builders, etc.). While the scripting may alleviate some repetition, it still nevertheless requires that the user, at least in the first instance, actually perform the programming.
One further consideration in these types of visual programming of this type is data compatibility in the various actions of the programmed workflow. For instance, consider a scenario in which a user first programs an action (not shown) that retrieves document files. An action to rotate an image would, at this point, would be incompatible, since the action needs an image input rather than a file input. These types of data incompatibilities can cause program faults and/or runtime errors fatal to the execution of the program. Thus, the user must be aware of and implement a strategy for converting data of the first type to data of the second type. This, again, requires knowledge skill requiring time and effort to acquire.
Programs and utilities that support automated scripting exist to permit users to create scripts of user-level commands that may span disparate programs or contexts. These programs and utilities are often simple programs without extensible features or modular “programming” and/or without the ability to resolve incongruities in the “program” being scripted.”
The present invention is directed to resolving, or at least reducing, one or all of the problems mentioned above.